In an environment in which machine-to-machine (M2M) devices are connected to an M2M service provider (SP) through an access network provided by another entity, the M2M service provider effectively creates a service layer on top of the access network. This service layer is used to deliver services to the M2M devices. Frameworks for providing M2M services have been developed by the European Telecommunications Standards Institute (ETSI) as well as by an organization known as one2M2M.
FIG. 1 illustrates the typical architecture of an M2M system as depicted in the ETSI specifications. The illustrated architecture includes an M2M Service Capabilities server 110, which provides at least one M2M Network Services Capabilities Layer (NSCL) 115 for one or more M2M applications 120, which may be implemented on the M2M Services Capabilities server 110 and/or on one or more other server nodes.
A Service Capability Layer (SCL) is an M2M concept standardized by ETSI, and represents an abstraction layer of the M2M software in which common functionalities are implemented to serve M2M applications. The software implementing the NSCL in the M2M server provides a set of application program interfaces (APIs) to expose the M2M service capabilities to the M2M applications. Corresponding SCLs can be found in the M2M device and/or in an M2M Gateway node, and are often referred to as DSCLs and GSCLs, respectively. An instantiation of the SCL is identified by an SCL identifier (SCL-ID) that is maintained by the M2M service provider and pre-configured in the device or acquired during a bootstrap process. Thus, an M2M DSCL in the M2M device corresponds directly to an M2M NSCL 115 in the M2M server 110.
FIG. 1 also illustrates three different types of M2M devices. A first type is devices hidden behind gateways and that are thus not visible to the M2M NSCL, which is the main core network node. In FIG. 1, these devices are labeled M2M D1-M2M D6. A second type is devices not hidden behind gateways and visible to the M2M NSCL. In FIG. 1, these devices are labeled M2M D7 and M2M D8. A third type is gateways visible to the M2M NSCL and handling hidden devices. These gateways are labeled M2M G1 and M2M G2 in FIG. 1.
Note that hidden devices, gateways, and devices visible to the M2M NSCL can each have applications that communicate with the M2M NSCL. However applications on devices hidden behind the gateways can be reached only via the gateway to which they are connected.
More information on the current architecture can be found in the most current version of the ETSI document entitled “machine-to-machine Communication—Functional Architecture,” ETSI TS 102 690, which describes in more details the functions and interfaces shown in FIG. 1.
The oneM2M architecture for M2M systems is similar to the ETSI architecture and is depicted in FIG. 2. According to the oneM2M architecture, an M2M system can be divided into a field domain, in which device gateways and M2M devices reside, and the infrastructure domain, where network-based functions reside. In each domain are application entities (AEs), shown as Field Domain AE 210 and Infrastructure Domain AE 240 in FIG. 2, as well as Common Services Entities (CSEs), shown as Field Domain CSE 220 and Infrastructure Domain CSE 250 in FIG. 2. The AE provides application logic for specific end-to-end M2M solutions, such as for fleet tracking, remote power metering, etc. The CSE includes service functions that are common to the M2M environments and that are specified by oneM2M. These service functions are exposed to other entities through reference points Mca and Mcc. A network services entity (NSE) is also present in each domain, and is represented by NSE 230 and NSE 260 in FIG. 2. The NSE provides services such as device management, location services, and device triggering.
The NSCL in the ETSI architecture is equivalent to the infrastructure domain CSE 250 depicted in FIG. 2. The gateway in the ETSI architecture is equivalent to the field domain CSE 220 in FIG. 1. While ETSI defines only one gateway, oneM2M includes several gateways in its architecture. Further information on the oneM2M architecture can be found at http://www.onem2m.org. Detailed information can be found in the document “oneM2M Functional Architecture,” oneM2M-TS-0001-V-0.3.1 (December 2013).
As part of its definition of the M2M architecture, oneM2M has defined several different types of nodes that it foresees as being part of the typical M2M network deployment. FIG. 3 illustrates some of these nodes. From a purely architectural perspective, these nodes are functional/logical objects, and are not necessarily mapped to discrete physical devices, although any of them might be in any particular instance. One of these nodes is referred to as an Infrastructure Node (IN)—the IN resides in the Infrastructure Domain, contains one CSE, and may contain any number (including zero) of AEs. Typically, there would be just one IN in a deployment.
Another node is referred to as a Middle Node (MN)—a MN resides in the Field Domain, contains one CSE, and also may or may not contain one or more AEs. The functional/logical object known as the MN may reside in an M2M Gateway, for example. A MN can communicate with an IN and/or another MN and/or an Application Dedicated Node (ADN), which is a node that contains at least one AE but does not include a CSE.
Before a node can take advantage of services provided by the CSE of another node, it needs to register with that CSE. The M2M framework as currently defined has a limitation in is architecture with respect to MN-to-MN registration. An extract from Section 6.2.9.2 of the working version of the oneM2M Functional Architecture Baseline specification is reproduced below:                An MN-CSE shall support only a single registration towards another MN-CSE or an IN-CSE. A concatenation (registration chain) of multiple uni-directional registrations shall not form a loop. E.g. Two MN-CSEs A and B, shall not register with each other. Three MN-CSEs A, B and C, where A registers to B, and B registers to C, then C shall not register to A.        
An example of this restriction is shown in FIG. 4. As can be seen in the figure, because MN2 is registered with MN3, which in turn is registered with MN1, MN1 is not allowed to register with MN2, as this would create a loop. Procedures to ensure that this restriction is met are needed.